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RTP Stream Pause and Resume 
Abstract 


With the increased popularity of real-time multimedia applications, 
it is desirable to provide good control of resource usage, and users 
also demand more control over communication sessions. This document 
describes how a receiver in a multimedia conversation can pause and 
resume incoming data from a sender by sending real-time feedback 
messages when using the Real-time Transport Protocol (RTP) for real- 
time data transport. This document extends the Codec Control Message 
(CCM) RTP Control Protocol (RICP) feedback package by explicitly 
allowing and describing specific use of existing CCMs and adding a 
group of new real-time feedback messages used to pause and resume RTP 
data streams. This document updates RFC 5104. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7728. 
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Introduction 


As real-time communication attracts more people, more applications 
are created; multimedia conversation applications is one example. 
Multimedia conversation further exists in many forms, for example, 
peer-to-peer chat application and multiparty video conferencing 
controlled by central media nodes, such as RTP Mixers. 


Multimedia conferencing may involve many participants; each has its 
own preferences for the communication session, not only at the start 
but also during the session. This document describes several 
scenarios in multimedia communication where a conferencing node or 
participant chooses to temporarily pause an incoming RTP [RFC3550] 
stream and later resume it when needed. The receiver does not need 
to terminate or inactivate the RTP session and start all over again 
by negotiating the session parameters, for example, using SIP 
[RFC3261] with the Session Description Protocol (SDP) [RFC4566] 
offer/answer [RFC3264]. 


Centralized nodes, like RTP Mixers or Multipoint Control Units (MCUs) 
that use either logic based on voice activity, other measurements, or 
user input could reduce the resources consumed in both the sender and 
the network by temporarily pausing the RTP streams that aren’t 
required by the RTP Mixer. If the number of conference participants 
are greater than what the conference logic has chosen to present 
simultaneously to receiving participants, some participant RTP 
streams sent to the RTP Mixer may not need to be forwarded to any 
other participant. Those RTP streams could then be temporarily 
paused. This becomes especially useful when the media sources are 
provided in multiple encoding versions (Simulcast) [SDP-SIMULCAST] or 
with Multi-Session Transmission (MST) of scalable encoding such as 
Scalable Video Coding (SVC) [RFC6190]. There may be some of the 
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defined encodings or a combination of scalable layers that are not 
used or cannot be used all of the time. As an example, a centralized 
node may choose to pause such unused RTP streams without being 
explicitly requested to do so, maybe due to temporarily limited 
network or processing resources. It may then also send an explicit 
indication that the streams are paused. 


As the set of RTP streams required at any given point in time is 
highly dynamic in such scenarios, using the out-of-band signaling 
channel for pausing, and even more importantly resuming, an RTP 
stream is difficult due to the performance requirements. Instead, 
the pause and resume signaling should be in the media plane and go 
directly between the affected nodes. When using RTP [RFC3550] for 
media transport, using "Extended RTP Profile for Real-time Transport 
Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] appears 
appropriate. No currently existing RTCP feedback message explicitly 
supports pausing and resuming an incoming RTP stream. As this 
affects the generation of packets and may even allow the encoding 
process to be paused, the functionality appears to match Codec 
Control Messages (CCMs) in the RTP Audio-Visual Profile with Feedback 
(AVPF) [RFC5104]. This document defines the solution as a CCM 
extension. 


The Temporary Maximum Media Bitrate Request (TMMBR) message of CCM is 
used by video conferencing systems for flow control. It is desirable 
to be able to use that method with a bitrate value of zero for pause, 
whenever possible. This specification updates RFC 5104 by adding the 
new pause and resume semantics to the TMMBR and Temporary Maximum 
Media Bitrate Notification (TMMBN) messages. 


Definitions 


1. Abbreviations 


AVPF: Audio-Visual Profile with Feedback (RFC 4585) 
CCM: Codec Control Message (RFC 5104) 

CNAME: Canonical Name (RTCP Source Description) 
CSRC: Contributing Source (RTP) 

FCI: Feedback Control Information (AVPF) 

FIR: Full Intra Refresh (CCM) 

EMT: Feedback Message Type (AVPF) 
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MCU: 


MTU: 


PT} 


RTP: 


RTCP: 


RTCP RR: 


RTCP SR: 


SDP: 


SIP; 


SSRC: 


SVC: 


TMMBR: 


TMMBN: 


UA: 


UDP: 
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Multipoint Control Unit 

Maximum Transfer Unit 

Payload Type (RTP) 

Real-time Transport Protocol (RFC 3550) 

RTP Control Protocol (RFC 3550) 

RTCP Receiver Report 

RICP Sender Report 

Session Description Protocol (RFC 4566) 
Session Initiation Protocol (RFC 3261) 
Synchronization Source (RTP) 

Scalable Video Coding 

Temporary Maximum Media Bitrate Request (CCM) 
Temporary Maximum Media Bitrate Notification (CCM) 
User Agent (SIP) 


User Datagram Protocol (RFC 768) 


2.2. Terminology 


In addition to the following, the definitions from RTP [RFC3550], 
AVPF [RFC4585], CCM [RFC5104], and RTP Taxonomy [RFC7656] also apply 
in this document. 


Feedback Messages: CCM [RFC5104] categorized different RTCP feedback 
messages into four types: Request, Command, Indication, and 


Notification. 


This document places the PAUSE and RESUME messages 


into the Request category, PAUSED as an Indication, and REFUSED as 
a Notification. 


PAUSE: Request from an RTP stream receiver to pause a stream 
RESUME: Request from an RTP stream receiver to resume a paused 
stream 
Burman, et al. Standards Track [Page 6] 
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PAUSED: Indication from an RTP stream sender that a stream is 
paused 


REFUSED: Notification from an RTP stream sender that a PAUSE or 
RESUME request will not be honored 


Mixer: The intermediate RTP node that receives an RTP stream from 
different endpoints, combines them to make one RTP stream, and 
forwards them to destinations, in the sense described for Topo- 
Mixer in "RTP Topologies" [RFC7667]. 


Participant: A member that is part of an RTP session, acting as the 
receiver, sender, or both. 


Paused sender: An RTP stream sender that has stopped its 
transmission, i.e., no other participant receives its RTP 
transmission, based on having received either a PAUSE request, 
defined in this specification, or a local decision. 


Pausing receiver: An RIP stream receiver that sends a PAUSE request, 
defined in this specification, to another participant (s). 


Stream: Used as a short term for RTP stream, unless otherwise noted. 


Stream receiver: Short for RTP stream receiver; the RTP entity 
responsible for receiving an RTP stream, usually a Media 
Depacketizer. 

Stream sender: Short for RTP stream sender; the RTP entity 
responsible for creating an RTP stream, usually a Media 
Packetizer. 


2.3. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 


"OPTIONAL" in this document are to be interpreted as described in RFC 
2119 [RFC2119]. 
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Use Cases 


This section discusses the main use cases for RTP stream pause and 
resume. 


The RTCWEB WG's use case and requirements document [RFC7478] defines 
the following API requirements in Appendix A, which is also used by 
the W3C WebRTC WG: 


A8 The web API must provide means for the web application to mute/ 


unmute a stream or stream component(s). When a stream is sent to 
a peer, mute status must be preserved in the stream received by 
the peer. 


A9 The web API must provide means for the web application to cease 
the sending of a stream to a peer. 


This document provides means to optimize transport usage by stopping 
the sending of muted streams and starting the sending of streams 
again when unmuted. Here, it is assumed that "mute" above can be 
taken to apply also to media other than audio. At the time of 
publication for this specification, the RTCWEB WG did not specify any 
pause/resume functionality. 


1. Point to Point 


This is the most basic use case with an RTP session containing two 


endpoints. Each endpoint sends one or more streams. 
++ +---+ 
| a |<------- >| B | 
+---+ +---+ 


Figure 1: Point to Point 


The usage of RTP stream pause in this use case is to temporarily halt 
delivery of streams that the sender provides but the receiver does 
not currently use. This can, for example, be due to minimized 
applications where the video stream is not actually shown on any 
display, or it is not used in any other way, such as being recorded. 
In this case, since there is only a single receiver of the stream, 
pausing or resuming a stream does not impact anyone else other than 
the sender and the single receiver of that stream. 
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3.2. RTP Mixer to Media Sender 


One of the most commonly used topologies in centralized conferencing 
is based on the RTP Mixer [RFC7667]. The main reason for this is 
that it provides a very consistent view of the RTP session towards 
each participant. That is accomplished through the Mixer originating 
its own streams, identified by distinct SSRC values, and any RTP 
streams sent to the participants will be sent using those SSRC 
values. If the Mixer wants to identify the underlying media sources 
for its conceptual streams, it can identify them using CSRC. The 
stream the Mixer provides can be an actual mix of multiple media 
sources, but it might also be switching received streams as described 
in Sections 3.6 - 3.8 of "RTP Topologies" [RFC7667]. 


+---+ 4----------- + +---+ 

| A |<----> <---->| B | 

+o--+ +o--+ 
| Mixer | 

+---+ | | +---+ 

| c [e| [>| p | 

+o--+ 4----------- + +=--+ 


Figure 2: RTP Mixer in Unicast Only 


Which streams from clients B, C, and D that are delivered to a given 
receiver, A, Can depend on several things: 


o The RTP Mixer’s own logic and measurements, such as voice activity 
on the incoming audio streams. 


o The number of sent media sources exceed what is reasonable to 
present simultaneously at any given receiver. 


o A human controlling the conference that determines how the media 
should be mixed. This would be more common in lecture or similar 
applications where regular listeners may be prevented from 
breaking into the session unless approved by the moderator. 


o The streams may also be part of a Simulcast [SDP-SIMULCAST] or 
scalable encoded (for Multi-Session Transmission) [RFC6190], thus 
providing multiple versions that can be delivered by the RTP 
stream sender. 


These examples indicate that there are numerous reasons why a 
particular stream would not currently be in use but must be available 
for use at very short notice if any dynamic event occurs that causes 
a different stream selection to be done in the Mixer. 
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Because of this, it would be highly beneficial if the Mixer could 
request the RTP stream sender to pause a particular stream. The 
Mixer also needs to be able to request the RTP stream sender to 
resume delivery with minimal delay. 


In some cases, especially when the Mixer sends multiple RTP streams 
per receiving client, there may be situations that make it desirable 
for the Mixer to pause some of its sent RTP streams, even without 
being explicitly asked to do so by the receiving client. Such 
situations can, for example, be caused by a temporary lack of 
available Mixer network or processing resources. An RIP stream 
receiver that no longer receives an RTP stream could interpret this 
as an error condition and try to take action to re-establish the RTP 
stream. Such action would likely be undesirable if the RTP stream 
was in fact deliberately paused by the Mixer. Undesirable RTP stream 
receiver actions could be avoided if the Mixer is able to explicitly 
indicate that an RTP stream is deliberately paused. 


Just as for point to point (Section 3.1), there is only a single 
receiver of the stream, the RTP Mixer, and pausing or resuming a 
stream does not affect anyone else other than the sender and single 
receiver of that stream. 


.3. RTP Mixer to Media Sender in Point to Multipoint 


This use case is similar to the previous section; however, the RTP 
Mixer is involved in three domains that need to be separated: the 
Multicast Network (including participants A and C), participant B, 
and participant D. The difference from above is that A and C share a 
multicast domain, which is depicted below. 


Ho + 
t---— / N T----------- t ++ 
| A |<---/ \ «----»| B | 
*---t / Multi- \ *---t 
* cast *-»| Mixer | 
+---+ \ Network / | | T--— 
| o [ea Al [sees epp] 
+---+ \ / HE + T---t 
poorer * 


Figure 3: RTP Mixer in Point to Multipoint 


If the RTP Mixer pauses a stream from A, it will not only pause the 
stream towards itself but will also stop the stream from arriving to 
C, which C is heavily impacted by, might not approve of, and should 
thus have a say on. 
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If the Mixer resumes a paused stream from A, it will be resumed also 
towards C. In this case, if C is not interested, it can simply 
ignore the stream and is not impacted as much as above. 


In this use case, there are several receivers of a stream, and the 
Mixer must take special care so as not to pause a stream that is 
still wanted by some receivers. 


3.4. Media Receiver to RTP Mixer 


In this use case, the direction of the request to pause is the 
opposite compared to the two previous use cases. An endpoint in 
Figure 2 could potentially request to pause the delivery of a given 
stream. Possible reasons include those in the point-to-point case 
(Section 3.1) above. 


When the RTP Mixer is only connected to individual unicast paths, the 
use case and any considerations are identical to the point-to-point 
use case. 


However, when the endpoint requesting stream pause is connected to 
the RTP Mixer through a multicast network, such as A or C in 
Figure 3, the use case instead becomes identical to the one in 
Section 3.3, only with reverse direction of the streams and pause/ 
resume requests. 


3.5. Media Receiver to Media Sender across RTP Mixer 


An endpoint, like A in Figure 2, could potentially request to pause 
the delivery of a given stream, like one of B’s, over any of the 
SSRCs used by the Mixer by sending a pause request for the CSRC 
identifying the stream. However, the authors are of the opinion that 
this is not a suitable solution for several reasons: 


1. The Mixer might not include CSRC in its stream indications. 

2. An endpoint cannot rely on the CSRC to correctly identify the 
stream to be paused when the delivered media is some type of mix. 
A more elaborate stream identification solution is needed to 


support this in the general case. 


3. The endpoint cannot determine if a given stream is still needed 
by the RTP Mixer to deliver to another session participant. 


Due to the above reasons, we exclude this use case from further 
consideration. 
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4. Design Considerations 


This section describes the requirements that this specification needs 
to meet. 


4.1. Real-Time Nature 


The first section (Section 1) of this specification describes some 
possible reasons why a receiver may pause an RTP sender. Pausing and 
resuming is time dependent, i.e., a receiver may choose to pause an 
RTP stream for a certain duration, after which the receiver may want 
the sender to resume. This time dependency means that the messages 
related to pause and resume must be transmitted to the sender ina 
timely fashion in order for them to be purposeful. The pause 
operation is arguably not as time critical as the resume operation, 
since it mainly provides a reduction of resource usage. Timely 
handling of the resume operation is, however, likely to directly 
impact the end-user’s perceived quality experience, since it affects 
the availability of media that the user expects to receive more or 
less instantly. It may also be highly desirable for a receiver to 
quickly learn that an RTP stream is intentionally paused on the RTP 
sender’s own behalf. 


4.2. Message Direction 


It is the responsibility of an RTP stream receiver that wants to 
pause or resume a stream from the sender(s) to transmit PAUSE and 
RESUME messages. An RTP stream sender that wants to pause itself can 
often simply do it, but sometimes this will adversely affect the 
receiver and an explicit indication that the RTP stream is paused may 
then help. Any indication that an RTP stream is paused is the 
responsibility of the RTP stream sender and may in some cases not 
even be needed by the stream receiver. 


4.3. Apply to Individual Sources 


The PAUSE and RESUME messages apply to single RTP streams identified 
by their SSRC, which means the receiver targets the sender's SSRC in 
the PAUSE and RESUME requests. If a paused sender starts sending 
with a new SSRC, the receivers will need to send a new PAUSE request 
in order to pause it.  PAUSED indications refer to a single one of 
the sender's own paused SSRC. 


Burman, et al. Standards Track [Page 12] 


RFC 7728 RTP Stream Pause February 2016 


4.4. Consensus 


An RTP stream sender should not pause an SSRC that some receiver 
still wishes to receive. 


The reason is that in RTP topologies where the stream is shared 
between multiple receivers, a single receiver on that shared network 
must not single-handedly cause the stream to be paused without 
letting all other receivers voice their opinions on whether or not 
the stream should be paused. Such shared networks can, for example, 
be multicast, a mesh with a joint RTP session, or a transport 
Translator-based network. A consequence of this is that a newly 
joining receiver first needs to learn the existence of paused streams 
and secondly should be able to resume any paused stream. A newly 
joining receiver can, for example, be detected through an RTCP 
Receiver Report containing both a new SSRC and a CNAME that does not 
already occur in the session. Any single receiver wanting to resume 
a stream should also cause it to be resumed. An important exception 
to this is when the RIP stream sender is aware of conditions that 
make it desirable or even necessary to pause the RTP stream on its 
own behalf, without being explicitly asked to do so. Such local 
consideration in the RTP sender takes precedence over RIP receiver 
wishes to receive the stream. 


4.5. Message Acknowledgments 


RTP and RTCP does not guarantee reliable data transmission. It uses 
whatever assurance the lower-layer transport protocol can provide. 
However, this is commonly UDP that provides no reliability 
guarantees. Thus, it is possible that a PAUSE and/or RESUME message 
transmitted from an RTP endpoint does not reach its destination, 
i.e., the targeted RTP stream sender. When PAUSE or RESUME reaches 
the RTP stream sender and is effective, i.e., an active RTP stream 
sender pauses or a resuming RIP stream sender has media data to 
transmit, it is immediately seen from the arrival or non-arrival of 
RTP packets for that RTP stream. Thus, no explicit acknowledgments 
are required in this case. 


In some cases, when a PAUSE or RESUME message reaches the RTP stream 
sender, it will not be able to pause or resume the stream due to some 
local consideration, for example, lack of data to transmit. In this 
error condition, a negative acknowledgment may be needed to avoid 
unnecessary retransmission of requests (Section 4.6). 
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4.6. Request Retransmission 


When the stream is not affected as expected by a PAUSE or RESUME 
request, the request may have been lost and the sender of the request 
will need to retransmit it. The retransmission should take the 
round-trip time into account, and will also need to take the normal 
RTCP bandwidth and timing rules applicable to the RTP session into 
account, when scheduling retransmission of feedback. 


When it comes to resume requests or unsolicited paused indications 
that are more time critical, the best performance may be achieved by 
repeating the message as often as possible until a sufficient number 
have been sent to reach a high probability of message delivery or at 
an explicit indication that the message was delivered. For resume 
requests, such explicit indication can be delivery of the RTP stream 
being requested to be resumed. 


4.7. Sequence Numbering 


A PAUSE request message will need to have a sequence number to 
separate retransmissions from new requests. A retransmission keeps 
the sequence number unchanged, while it is incremented every time a 
new PAUSE request is transmitted that is not a retransmission of a 
previous request. 


Since RESUME always takes precedence over PAUSE and is even allowed 
to avoid pausing a stream, there is a need to keep strict ordering of 
PAUSE and RESUME. Thus, RESUME needs to share sequence number space 
with PAUSE and implicitly reference which PAUSE it refers to. For 
the same reasons, the explicit PAUSED indication also needs to share 
sequence number space with PAUSE and RESUME. 


4.8. Relation to Other Solutions 


A performance comparison between SIP/SDP and RTCP signaling 
technologies was made and included in draft versions of this 
specification. Using SIP and SDP to carry pause and resume 
information means that they will need to traverse the entire 
signaling path to reach the signaling destination (either the remote 
endpoint or the entity controlling the RTP Mixer) across any 
signaling proxies that potentially also have to process the SDP 
content to determine if they are expected to act on it. The amount 
of bandwidth required for a signaling solution based on SIP/SDP is in 
the order of at least 10 times more than an RTCP-based solution. 
Especially for a UA sitting on mobile wireless access, this will risk 
introducing delays that are too long (Section 4.1) to provide a good 
user experience, and the bandwidth cost may also be considered 
infeasible compared to an RTCP-based solution. RTCP data sent 
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through the media path, which is likely shorter (contains fewer 
intermediate nodes) than the signaling path, may have to traverse a 
few intermediate nodes anyway. The amount of processing and 
buffering required in intermediate nodes to forward those RTCP 
messages is, however, believed to be significantly less than for 
intermediate nodes in the signaling path. Based on those 
considerations, RTCP is chosen as the signaling protocol for the 
pause and resume functionality. 


5. Solution Overview 


The proposed solution implements pause and resume functionality based 
on sending AVPF RTCP feedback messages from any RTP session 
participant that wants to pause or resume a stream targeted at the 
stream sender, as identified by the sender SSRC. 


This solution reuses CCM TMMBR and TMMBN [RFC5104] to the extent 
possible and defines a small set of new RTCP feedback messages where 
new semantics is needed. 


A single feedback message specification is used to implement the new 
messages. The message consists of a number of Feedback Control 
Information (FCI) blocks, where each block can be a PAUSE request, a 
RESUME request, a PAUSED indication, a REFUSED notification, or an 
extension to this specification. This structure allows a single 
feedback message to handle pause functionality on a number of 
streams. 


The PAUSED functionality is also defined in such a way that it can be 
used as a standalone by the RTP stream sender to indicate a local 
decision to pause, and it can inform any receiver of the fact that 
halting media delivery is deliberate and which RTP packet was the 
last transmitted. 


Special considerations that apply when using TMMBR/TMMBN for pause 
and resume purposes are described in Section 5.6. This specification 
applies to both the new messages defined herein as well as their 
TMMBR/TMMBN counterparts, except when explicitly stated otherwise. 

An obvious exception is any reference to the message parameters that 
are only available in the messages defined here. For example, any 
reference to PAUSE in the text below is equally applicable to 

TMMBR 0, and any reference to PAUSED is equally applicable to TMMBN 
0. Therefore, and for brevity, TMMBR/TMMBN will not be mentioned in 
the text, unless there is specific reason to do so. 


This section is intended to be explanatory and therefore 
intentionally contains no mandatory statements. Such statements can 
instead be found in other parts of this specification. 
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5.1. Expressing Capability 


An endpoint can use an extension to CCM SDP signaling to declare 
capability to understand the messages defined in this specification. 
Capability to understand only a subset of messages is possible, to 
support partial implementation, which is specifically believed to be 
feasible for the 'RTP Mixer to Media Sender’ use case (Section 3.2). 
In that use case, only the RTP Mixer has capability to request the 
media sender to pause or resume. Consequently, in that same use 
case, only the media sender has capability to pause and resume its 
sent streams based on requests from the RTP Mixer. Allowing for 
partial implementation of this specification is not believed to 
hamper interoperability, as long as the subsets are well defined and 
describe a consistent functionality, including a description of how a 
more capable implementation must perform fallback. 


For the case when TMMBR/TMMBN are used for pause and resume purposes, 
it is possible to explicitly express joint support for TMMBR and 
TMMBN, but not for TMMBN only. 


5.2.  PauseID 


All messages defined in this specification (Section 8) contain a 
PauseID, satisfying the design consideration on sequence numbering 
(Section 4.7). This PauseID is scoped by and thus a property of the 
targeted RTP stream (SSRC) and is not only a sequence number for 
individual messages. Instead, it numbers an entire "pause and resume 
operation" for the RTP stream, typically keeping PauseID constant for 
multiple, related messages. The PauseID value used during such 
operation is called the current PauseID. A new "pause and resume 
operation" is defined to start when the RTP stream sender resumes the 
RTP stream after it was being paused. The current PauseID is then 
incremented by one in modulo arithmetic. In the subsequent 
descriptions below, it is sometimes necessary to refer to PauseID 
values that were already used as the current PauseID, which is 
denoted as the past PauseID. It should be noted that since PauseID 
uses modulo arithmetic, a past PauseID may have a larger value than 
the current PauseID. Since PauseID uses modulo arithmetic, it is 
also useful to define what PauseID values are considered "past" to 
clearly separate it from what could be considered "future" PauseID 


values. Half of the entire PauseID value range is chosen to 
represent a past PauseID, while a quarter of the PauseID value range 
is chosen to represent future values. The remaining quarter of the 


PauseID value range is intentionally left undefined in that respect. 
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5.3. Requesting to Pause 


An RTP stream receiver can choose to send a PAUSE request at any 
time, subject to AVPF timing rules. 


The PAUSE request contains the current PauseID (Section 5.2). 


When a non-paused RTP stream sender receives the PAUSE request, it 
continues to send the RTP stream while waiting for some time to allow 
other RIP stream receivers in the same RTP session that saw this 
PAUSE request to disapprove by sending a RESUME (Section 5.5) for the 
same stream and with the same current PauseID as in the PAUSE being 
disapproved. If such a disapproving RESUME arrives at the RTP stream 
sender during the hold-off period before the stream is paused, the 
pause is not performed. In point-to-point configurations, the hold- 
off period may be set to zero. Using a hold-off period of zero is 
also appropriate when using TMMBR 0 and is in line with the semantics 
for that message. 


If the RTP stream sender receives further PAUSE requests with the 
current PauseID while waiting as described above, those additional 
requests are ignored. 


If the PAUSE request is lost before it reaches the RTP stream sender, 
it will be discovered by the RIP stream receiver because it continues 
to receive the RIP stream. It will also not see any PAUSED 
indication (Section 5.4) for the stream. The same condition can be 
caused by the RTP stream sender having received a disapproving RESUME 
from stream receiver A for a PAUSE request sent by stream sender B, 
except that the PAUSE sender (B) did not receive the RESUME (from A) 
and may instead think that the PAUSE was lost. In both cases, a 
PAUSE request can be retransmitted using the same current PauselD. 

If using TMMBR 0, the request MAY be retransmitted when the requester 
fails to receive a TMMBN 0 confirmation. 


If the pending stream pause is aborted due to a disapproving RESUME, 
the pause and resume operation for that PauseID is concluded, the 
current PauseID is updated, and any new PAUSE must therefore use the 
new current PauseID to be effective. 


An RTP stream sender receiving a PAUSE not using the current PauselD 
informs the RTP stream receiver sending the ineffective PAUSE of this 
condition by sending a REFUSED notification that contains the current 
PauselD value. 


A situation where an ineffective PauseID is chosen can appear when a 


new RTP stream receiver joins a session and wants to PAUSE a stream 
but does not yet know the current PauselD to use. The REFUSED 
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notification will then provide sufficient information to create a 
valid PAUSE. The required extra signaling round trip is not 
considered harmful, since it is assumed that pausing a stream is not 
time critical (Section 4.1). 


There may be local considerations making it impossible or infeasible 
to pause the stream, and the RTP stream sender can then respond with 
a REFUSED. In this case, if the used current PauseID would otherwise 
have been effective, REFUSED contains the same current PauseID as in 
the PAUSE request. Note that when using TMMBR 0 as PAUSE, that 
request cannot be refused (TMMBN > 0) due to the existing restriction 
in Section 4.2.2.2 of [RFC5104] that TMMBN shall contain the current 
bounding set, and the fact that a TMMBR 0 will always be the most 
restrictive point in any bounding set, regardless of the bounding set 
overhead value. 


If the RTP stream sender receives several identical PAUSE requests 
for an RTP stream that was already responded to at least once with 
REFUSED and the condition causing REFUSED remains, those additional 
REFUSED notifications should be sent with regular RTCP timing. A 
single REFUSED can respond to several identical PAUSE requests. 


5.4. Media Sender Pausing 


An RTP stream sender Can choose to pause the stream at any time. 

This can be either a result of receiving a PAUSE or based on some 
local sender consideration. When it does, it sends a PAUSED 
indication, containing the current PauseID. Note that the current 
PauseID in an unsolicited PAUSED (without having received a PAUSE) is 
incremented compared to a previously sent PAUSED. It also sends the 
PAUSED indication in the next two regular RTCP reports, given that 
the pause condition is then still effective. 


There is no reply to a PAUSED indication; it is simply an explicit 
indication of the fact that an RTP stream is paused. This can be 
helpful for the RIP stream receiver, for example, to quickly 
understand that transmission is deliberately and temporarily 
suspended and no specific corrective action is needed. 


The RTP stream sender may want to apply some local consideration to 
exactly when the RTP stream is paused, for example, completing some 
media unit or a forward error correction block, before pausing the 
stream. 


The PAUSED indication also contains information about the RTP 
extended highest sequence number when the pause became effective. 
This provides RTP stream receivers with firsthand information that 
allows them to know whether they lost any packets just before the 
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stream paused or when the stream is resumed again. This allows RTP 
stream receivers to quickly and safely take into account that the 
stream is paused in, for example, retransmission or congestion 
control algorithms. 


If the RTP stream sender receives PAUSE requests with the current 
PauseID while the stream is already paused, those requests are 
ignored. 


As long as the stream is being paused, the PAUSED indication MAY be 
sent together with any regular RTCP Sender Report (SR) or Receiver 
Report (RR). Including PAUSED in this way allows RTP stream 
receivers to join while the stream is paused and to quickly know that 
there is a paused stream, what the last sent extended RTP sequence 
number is, and what the current PauseID is, which enables them to 
construct valid PAUSE and RESUME requests at a later stage. 


When the RTP stream sender learns that a new endpoint has joined the 
RTP session, for example, by a new SSRC and a CNAME that was not 
previously seen in the RTP session, it should send PAUSED indications 
for all its paused streams at its earliest opportunity. In addition, 
it should continue to include PAUSED indications in at least two 
regular RTCP reports. 


5.5. Requesting to Resume 


An RTP stream receiver can request the RTP stream sender to resume a 
stream with a RESUME request at any time, subject to AVPF timing 
rules. The RTP stream receiver must include the current PauselD in 
the RESUME request for it to be effective. 


A pausing RTP stream sender that receives a RESUME including the 
current PauseID resumes the stream at the earliest opportunity. 
Receiving RESUME requests for a stream that is not paused does not 
require any action and can be ignored. 


There may be local considerations at the RTP stream sender, for 
example, that the media device is not ready, making it temporarily 
impossible to resume the stream at that point in time, and the RTP 
stream sender can then respond with a REFUSED containing the current 
PauseID. When receiving such REFUSED with a current PauselD 
identical to the one in the sent RESUME, RTP stream receivers should 
avoid sending further RESUME requests for some reasonable amount of 
time to allow the condition to clear. An RTP stream sender having 
sent a REFUSED SHOULD resume the stream through local considerations 
(see below) when the condition that caused the REFUSED is no longer 
true. 
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If the RTP stream sender receives several identical RESUME requests 
for an RTP stream that was already at least once responded to with 
REFUSED and the condition causing REFUSED remains, those additional 
REFUSED notifications should be sent with regular RTCP timing. A 
single REFUSED can respond to several identical RESUME requests. 


A pausing RTP stream sender can apply local considerations and can 


resume a paused RTP stream at any time. If TMMBR 0 was used to pause 
the RTP stream, resumption is prevented by protocol, even if the RTP 
sender would like to resume due to local considerations. If TMMBR/ 


TMMBN signaling is used, the RTP stream is paused due to local 
considerations (Section 5.4), and the RTP stream sender thus owns the 
TMMBN bounding set, the RTP stream can be resumed due to local 
considerations. 


When resuming a paused stream, especially for media that makes use of 
temporal redundancy between samples such as video, it may not be 
appropriate to use such temporal dependency in the encoding between 
samples taken before the pause and at the time instant the stream is 
resumed. Should such temporal dependency between media samples 
before and after the media was paused be used by the RTP stream 
sender, it requires the RTP stream receiver to have saved the samples 
from before the pause for successful continued decoding when 
resuming. The use of this temporal dependency of media samples from 
before the pause is left up to the RTP stream sender. If temporal 
dependency on samples from before the pause is not used when the RTP 
stream is resumed, the first encoded sample after the pause will not 
contain any temporal dependency on samples before the pause (for 
video it may be a so-called intra picture). If temporal dependency 
on samples from before the pause is used by the RTP stream sender 
when resuming, and if the RTP stream receiver did not save any sample 
from before the pause, the RTP stream receiver can use a FIR request 
[RFC5104] to explicitly ask for a sample without temporal dependency 
(for video a so-called intra picture), even at the same time as 
sending the RESUME. 


5.6.  TMMBR/TMMBN Considerations 


As stated above, TMMBR/TMMBN may be used to provide pause and resume 
functionality for the point-to-point case. If the topology is not 
point to point, TMMBR/TMMBN cannot safely be used for pause or 
resume. This use is expected to be mainly for interworking with 
implementations that don't support the messages defined in this 
specification (Section 8) but make use of TMMBR/TMMBN to achieve a 
similar effect. 
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This is a brief summary of what functionality is provided when using 
TMMBR/TMMBN: 


TMMBR 0: Corresponds to PAUSE, without the requirement for any hold- 
off period to wait for RESUME before pausing the RTP stream. 


TMMBR > 0: Corresponds to RESUME when the RTP stream was previously 
paused with TMMBR 0. Since there is only a single RTP stream 
receiver, there is no need for the RTP stream sender to delay 
resuming the stream until after sending TMMBN > 0 or to apply the 
hold-off period specified in [RFC5104] before increasing the 
bitrate from zero. The bitrate value used when resuming after 
pausing with TMMBR 0 is either according to known limitations or 
based on starting a stream with the configured maximum for the 
stream or session, for example, given by "b=" line in SDP. 


TMMBN 0: Corresponds to PAUSED when the RTP stream was paused with 
TMMBR 0 but may, just as PAUSED, also be used unsolicited. An 
unsolicited RTP stream pause based on local sender considerations 
uses the RTP stream’s own SSRC as the TMMBR restriction owner in 
the TMMBN message bounding set. It also corresponds to a REFUSED 
notification when a stream is requested to be resumed with 
TMMBR > 0, thus resulting in the stream sender becoming the owner 
of the bounding set in the TMMBN message. 


TMMBN > 0: Cannot be used as a REFUSED notification when a stream is 


requested to be paused with TMMBR 0, for reasons stated in 
Section 5.3. 
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6. Participant States 


This document introduces three new states for a stream in an RTP 
sender, according to the figure and subsections below. Any 
references to PAUSE, PAUSED, RESUME, and REFUSED in this section 
SHALL be taken to apply to the extent possible also when TMMBR/TMMBN 
are used (Section 5.6) for this functionality. 


A O 5 5 = + 
| Received RESUME | 
v 
4--------- + Received PAUSE  *--------- + Hold-off period -4-------- t 
| Playing | SoS dr E >| Pausing |---------------- >| Paused | 
<————— 
T--------- + Received RESUME «*--------- + Ho + 
^ | PAUSE decision 
| y 
| | PAUSE decision +--------- * PAUSE decision | 
| +------------------ >| Local = |<-------------------- + 
PSPS SSS TSR Ses S | Paused | 
RESUME decision ici aci + 


Figure 4: RTP Pause States in Sender 
6.1. Playing State 


This state is not new but is the normal media sending state from 
[RFC3550]. When entering the state, the current PauseID MUST be 
incremented by one in modulo arithmetic. The RTP sequence number for 
the first packet sent after a pause SHALL be incremented by one 
compared to the highest RTP sequence number sent before the pause. 
The first RTP timestamp for the first packet sent after a pause 
SHOULD be set according to capture times at the source, meaning the 
RTP timestamp difference compared to before the pause reflects the 
time the RTP stream was paused. 


6.2. Pausing State 


In this state, the RTP stream sender has received at least one PAUSE 
message for the stream in question. The RTP stream sender SHALL wait 
during a hold-off period for the possible reception of RESUME 
messages for the RTP stream being paused before actually pausing RTP 
stream transmission. The hold-off period to wait SHALL be long 
enough to allow another RIP stream receiver to respond to the PAUSE 
with a RESUME, if it determines that it would not like to see the 
stream paused. This hold-off period is determined by the formula: 


2 * RTT + T_dither_max, 
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where RTT is the longest round trip known to the RTP stream sender 
and T_dither_max is defined in Section 3.4 of [RFC4585]. The hold- 
off period MAY be set to 0 by some signaling (Section 9) means when 
it can be determined that there is only a single receiver, for 
example, in point to point or some unicast situations. 


If the RTP stream sender has set the hold-off period to 0 and 
receives information that it was an incorrect decision and that there 
are in fact several receivers of the stream, it MUST change the hold- 
off period to be based on the above formula instead. 


An RTP stream sender SHOULD use the following criteria to determine 
if there is only a single receiver, unless it has explicit and more 
reliable information: 


o Observing only a single CNAME across all received SSRCs (CNAMEs 
for received CSRCs are insignificant), or 


o If RTCP reporting groups [MULTI-STREAM-OPT] is used, observing 
only a single, endpoint external RICP reporting group. 


6.3. Paused State 


An RTP stream is in paused state when the sender pauses its 
transmission after receiving at least one PAUSE message and the hold- 
off period has passed without receiving any RESUME message for that 
stream. Pausing transmission SHOULD only be done when reaching an 
appropriate place to pause in the stream, like a media boundary that 
avoids a media receiver to trigger repair or concealment actions. 


When entering the state, the RIP stream sender SHALL send a PAUSED 
indication to all known RTP stream receivers, and SHALL also repeat 
PAUSED in the next two regular RICP reports, as long as it is then 
still in paused state. 


Pausing an RTP stream MUST NOT affect the sending of RTP keepalive 
[RFC6263] [RFC5245] applicable to that RTP stream. 


The following subsections discuss some potential issues when an RTP 
sender goes into paused state. These conditions are also valid if an 
RTP Translator is used in the communication. When an RTP Mixer 
implementing this specification is involved between the participants 
(which forwards the stream by marking the RTP data with its own 
SSRC), it SHALL be a responsibility of the Mixer to control sending 
PAUSE and RESUME requests to the sender. The below conditions also 
apply to the sender and receiver parts of the RTP Mixer, 
respectively. 
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6.3.1. RTCP BYE Message 


When a participant leaves the RTP session, it sends an RTCP BYE 
message. In addition to the semantics described in Sections 6.3.4 
and 6.3.7 of RTP [RFC3550], the following two conditions MUST also be 
considered when an RTP participant sends an RTCP BYE message: 


o If a paused sender sends an RTCP BYE message, receivers observing 
this SHALL NOT send further PAUSE or RESUME requests to it. 


o Since a sender pauses its transmission on receiving the PAUSE 
requests from any receiver in a session, the sender MUST keep 
record of which receiver caused the RTP stream to pause. If that 
receiver sends an RTCP BYE message observed by the sender, the 
sender SHALL resume the RTP stream. No receivers that were in the 
RTP session when the stream was paused objected that the stream 
was paused, but if there were so far undetected receivers added to 
the session during pause, those may not have learned about the 
existence of the paused stream because either there was no PAUSED 
sent for the paused RTP stream or those receivers did not support 
PAUSED.  Resuming the stream when the pausing party leaves the RTP 
session allows those potentially undetected receivers to learn 
that the stream exists. 


6.3.2. SSRC Time-Out 


Section 6.3.5 in RTP [RFC3550] describes the SSRC time-out of an RTP 
participant. Every RTP participant maintains a sender and receiver 
list in a session. If a participant does not get any RTP or RTCP 
packets from some other participant for the last five RTCP reporting 
intervals, it removes that participant from the receiver list. Any 
Streams that were paused by that removed participant SSRC SHALL be 
resumed. 


6.4. Local Paused State 


This state can be entered at any time, based on local decision from 
the RTP stream sender.  Pausing transmission SHOULD only be done when 
reaching an appropriate place to pause in the stream, like a media 
boundary that avoids a media receiver to trigger repair or 
concealment actions. 


As with paused state (Section 6.3), the RTP stream sender SHALL send 
a PAUSED indication to all known RTP stream receivers, when entering 
the state, unless the stream was already in paused state 

(Section 6.3). Such PAUSED indication SHALL be repeated a sufficient 
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number of times to reach a high probability that the message is 
correctly delivered, stopping such repetition whenever leaving the 
state. 


When using TMMBN 0 as a PAUSED indication and when already in paused 
state, the actions when entering local paused state depends on the 
bounding set overhead value in the received TMMBR 0 that caused the 
paused state and the bounding set overhead value used in (the RTP 
stream sender’s own) TMMBN 0: 


TMMBN 0 overhead <= TMMBR 0 overhead: The RTP stream sender SHALL 
NOT send any new TMMBN 0 replacing that active (more restrictive) 
bounding set, even if entering local paused state. 


TMMBN 0 overhead > TMMBR 0 overhead: The RIP stream sender SHALL 
send TMMBN 0 with itself in the TMMBN bounding set when entering 
local paused state. 


The case above, when using TMMBN 0 as a PAUSED indication, being in 
local paused state, and having received a TMMBR 0 with a bounding set 
overhead value greater than the value the RTP stream sender would 
itself use in a TMMBN 0, requires further consideration and is for 
clarity henceforth referred to as "restricted local paused state". 


As indicated in Figure 4, local paused state has higher precedence 
than paused state (Section 6.3), and RESUME messages alone cannot 
resume a paused RTP stream as long as the local decision still 
applies. An RTP stream sender in local paused state is responsible 
for leaving the state whenever the conditions that caused the 
decision to enter the state no longer apply. 


If the RTP stream sender is in restricted local paused state, it 
cannot leave that state until the TMMBR 0 limit causing the state is 
removed by a TMMBR > 0 (RESUME). If the RIP stream sender then needs 
to stay in local paused state due to local considerations, it MAY 
continue pausing the RTP stream by entering local paused state and 
MUST then act accordingly, including sending a TMMBN 0 with itself in 
the bounding set. 


Pausing an RTP stream MUST NOT affect the sending of RTP keepalive 
[RFC6263] [RFC5245] applicable to that RTP stream. 


When leaving the local paused state, the stream state SHALL become 
Playing, regardless of whether or not there were any RTP stream 
receivers that sent PAUSE for that stream during the local paused 
state, effectively clearing the RTP stream sender's memory for that 
stream. 
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7. 


Message Format 


Section 6 of AVPF [RFC4585] defines three types of low-delay RTCP 
feedback messages, i.e., transport-layer, payload-specific, and 
application-layer feedback messages. This document defines a new 
transport-layer feedback message, which is further subtyped into 
either a PAUSE request, a RESUME request, a PAUSED indication, or a 
REFUSED notification. 


The transport-layer feedback messages are identified by having the 
RTCP payload type be RTPFB (205) as defined by AVPF [RFC4585]. This 
transport-layer feedback message, containing one or more of the 
subtyped messages, is henceforth referred to as the PAUSE-RESUME 


message. The specific FCI format is identified by a Feedback Message 
Type (FMT) value in a common packet header for the feedback message 
defined in Section 6.1 of AVPF [RFC4585]. The PAUSE-RESUME 


transport-layer feedback message FCI is identified by FMT value = 9. 


The Common Packet Format for feedback messages defined by AVPF 
[RFC4585] is: 


0 1 2 3 
0-1-2:.3.4 5 6 7 & 9.012 3. 4.5.6 7] 8 9 0.12 34 590 78-910: 1 
R—R—-R-R-R RR RM] LR BRL] RB] RERBA 
|v=2|P| FMT | PT | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 

| SSRC of packet sender 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 

| SSRC of media source 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
Feedback Control Information (FCI) 


Figure 5: AVPF Common Feedback Message Packet Format 


For the PAUSE-RESUME message defined in this memo, the following 
interpretations of the packet fields apply: 


FMT: The FMT value identifying the PAUSE-RESUME FCI: 9 
PT: Payload Type = 205 (RTPFB) 


Length: As defined by AVPF, i.e., the length of this packet in 
32-bit words minus one, including the header and any padding. 
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SSRC of packet sender: The SSRC of the RIP session participant 
sending the messages in the FCI. Note, for endpoints that have 
multiple SSRCs in an RTP session, any of its SSRCs MAY be used to 
send any of the pause message types. 


SSRC of media source: Not used; SHALL be set to 0. The FCI 
identifies the SSRC the message is targeted for. 


The FCI field consists of one or more PAUSE, RESUME, PAUSED, or 
REFUSED messages or any future extension. These messages have the 
following FCI format: 


0 1 2 3 
01234567890123456789012345678<901 
tata A + dd de dd — + dd + dd + $ 4 +++ +++ +++ +++ +++ 
| Target SSRC | 
tata A + dd + dd + dd + $ 4 + dd +++ + +++ +++ ++ +++ 

| Type | Res Parameter Len | PauselD 

PR dh dd — + dd + dd + dd + $ 4 +++ +++ +++ +++ +++ 
Type Specific : 

PR a dd + dd + dd + dd + $ 4 ++ d+ +++ +++ +++ +++ 


Figure 6: Syntax of FCI Entry in the PAUSE and RESUME Message 

The FCI fields have the following definitions: 

Target SSRC (32 bits): For a PAUSE-RESUME message, this value is the 
SSRC that the request is intended for. For PAUSED, it MUST be the 
SSRC being paused. If pausing is the result of a PAUSE request, 
the value in PAUSED is effectively the same as Target SSRC in a 
related PAUSE request. For REFUSED, it MUST be the Target SSRC of 
the PAUSE or RESUME request that cannot change state. A CSRC MUST 
NOT be used as a target as the interpretation of such a request is 


unclear. 


Type (4 bits): The pause feedback type. The values defined in this 
specification are as follows: 


0: PAUSE request message. 
1: RESUME request message. 
2: PAUSED indication message. 


3: REFUSED notification message. 
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4-15: Reserved for future use. FCI fields with these Type values 
SHALL be ignored on reception by receivers and MUST NOT be used 
by senders implementing this specification. 


Res: (4 bits): Type Specific reserved. It SHALL be ignored by 
receivers implementing this specification and MUST be set to 0 by 
senders implementing this specification. 


Parameter Len (8 bits): Length of the Type Specific field in 32-bit 
words. MAY be 0. 


PauseID (16 bits): Message sequence identification, as described in 
Section 5.2. SHALL be incremented by one modulo 2%16 for each new 
PAUSE message, unless the message is retransmitted. The initial 
value SHOULD be 0. The PauseID is scoped by the Target SSRC, 
meaning that PAUSE, RESUME, and PAUSED messages therefore share 
the same PauseID space for a specific Target SSRC. 


Type Specific (variable): Defined per pause feedback type. MAY be 
empty. A receiver implementing this specification MUST be able to 
skip and ignore any unknown Type Specific data, even for Type 
values defined in this specification. 


8. Message Details 


This section contains detailed explanations of each message defined 
in this specification. All transmissions of requests and indications 
are governed by the transmission rules as defined by Section 8.5. 


Any references to PAUSE, PAUSED, RESUME, and REFUSED in this section 
SHALL be taken to apply to the extent possible and also when TMMBR/ 
TMMBN are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY 
be used instead of the messages defined in this specification when 
the effective topology is point to point. This use is expected to be 
mainly for interworking with implementations that don’t support the 
messages defined in this specification but make use of TMMBR/TMMBN to 


achieve a similar effect. If either sender or receiver learns that 
the topology is not point to point, TMMBR/TMMBN MUST NOT be used for 
pause/resume functionality. If the messages defined in this 


specification are supported in addition to TMMBR/TMMBN by all 
involved parties, pause/resume signaling MUST use messages from this 
specification. If the topology is not point to point and the 
messages defined in this specification are not supported, pause/ 
resume functionality with TMMBR/TMMBN MUST NOT be used. 


For the scope of this specification, a past PauseID (Section 5.2) is 


defined as having a value between and including (PauseID - 2^15) MOD 
2^16 and (PauseID - 1) MOD 2^16, where "MOD" is the modulo operator. 
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Similarly, a future PauseID is defined as having a value between and 
including (PauseID + 1) MOD 2^16 and (PauseID + 2^14) MOD 2^16. It 
is intentional that future PauseID is not defined as the entire range 
outside that of past PauseID. The remaining range of PauselD is 
simply "not current". 


8.1. PAUSE 


An RTP stream receiver MAY schedule PAUSE for transmission at any 
time. 


PAUSE has no defined Type Specific parameters. 


PauseID SHOULD be the current PauselD, as indicated by PAUSED 
(Section 8.2), REFUSED (Section 8.4), or implicitly determined by 
previously received PAUSE or RESUME (Section 8.3) requests. A 
randomly chosen PauseID MAY be used if it was not possible to 
retrieve current PauseID information, in which case the PAUSE will 
either succeed or the current PauseID can be found in the returned 
REFUSED (Section 8.4). 


It can be noted that as a result of what is described in Section 6.1, 
PauseID is incremented by one, in modulo arithmetic, for each PAUSE 
request that is not a retransmission, compared to what was used in 
the last PAUSED indication sent by the media sender.  PauseID in the 
message is supposed to match current PauselD at the RTP stream 
sender. 


If an RTP stream receiver that sent a PAUSE with a certain PauselD 
for a Target SSRC receives a RESUME or a REFUSED with the same 
PauselD for the same Target SSRC, it is RECOMMENDED that it refrains 
from scheduling further PAUSE requests for some appropriate time. 
This is because the RESUME indicates that there are other receivers 
that still wish to receive the stream, and the REFUSED indicates that 
the RTP stream sender is currently not able to pause the stream. 

What is an appropriate time can vary from application to application 
and will also depend on the importance of achieving the bandwidth 
saving, but 2-5 regular RTCP intervals is expected to be appropriate. 


If the targeted RTP stream does not pause, if no PAUSED indication 
with a future PauseID compared to the one used in PAUSE is received, 
and if no REFUSED with the current or a future PauseID is received 
within 2 * RTT + T_dither_max, the PAUSE MAY be scheduled for 
retransmission, using the same current PauseID. RTT is the observed 
round trip to the RTP stream sender, and T dither max is defined in 
Section 3.4 of [RFC4585]. An RTP stream receiver in a bi-directional 
RTP communication will generally have an RTT estimate to the RIP 
stream sender, e.g., from RTCP SR/RR as described in Section 6.4 of 
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[RFC3550]. However, RTP stream receivers that don't send any RTP 
streams will lack an RTT estimate unless they use additional 
mechanisms, such as the "Receiver Reference Time Report Block" part 
of RTCP XR [RFC3611]. RTP stream receivers that lack an RTT estimate 
to the sender SHOULD use 500 ms as the default value. 


When an RTP stream sender in playing state (Section 6.1) receives a 
PAUSE with the current PauselD, and unless local considerations 
currently make it impossible to pause the stream, it SHALL enter 
pausing state (Section 6.2) and act accordingly. 


If an RTP stream sender receives a PAUSE with the current PauselD 
while in pausing, paused (Section 6.3), or local paused (Section 6.4) 
states, the received PAUSE SHALL be ignored. 


8.2. PAUSED 


The PAUSED indication, if supported, MUST be sent whenever entering 
paused state (Section 6.3) or local paused state (Section 6.4). 


PauseID in the PAUSED message MUST contain the current PauseID that 
can be included in a subsequent RESUME (Section 8.3). For local 
paused state, this means that PauseID in the message is the current 
PauseID, just as if the RTP stream sender had sent a PAUSE to itself. 


PAUSED SHALL contain a fixed-length 32-bit parameter at the start of 
the Type Specific field with the extended RTP sequence number of the 
last RTP packet sent before the RIP stream was paused, in the same 
format as the extended highest sequence number received 

(Section 6.4.1 of [RFC3550]). 


After having entered paused or local paused state and thus having 
sent PAUSED once, PAUSED MUST also be included in (at least) the next 
two regular RTCP reports, given that the pause condition is then 
still effective. 


PAUSED indications MAY be retransmitted, subject to transmission 
rules (Section 8.5), to increase the probability that the message 
reaches the receiver in a timely fashion. This can be especially 
important when entering local paused state. The number of 
repetitions to use could be tuned to observed loss rate and desired 
loss probability, for example, based on RTCP reports received from 
the intended message target. 


While remaining in paused or local paused states, PAUSED MAY be 
included in all compound RTCP reports, as long as the negotiated RTCP 
bandwidth is not exceeded. 
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When in paused or local paused states, whenever the RTP stream sender 
learns that there are endpoints that did not previously receive the 
stream, for example, by RTCP reports with an SSRC and a CNAME that 
were not previously seen in the RTP session, it is RECOMMENDED to 
send PAUSED at the earliest opportunity and also to include it in (at 
least) the next two regular RICP reports, given that the pause 
condition is then still effective. 


8.3. RESUME 


An RTP stream receiver MAY schedule RESUME for transmission whenever 
it wishes to resume a paused stream or disapprove a stream from being 
paused. 


PauseID SHOULD be the current PauseID, as indicated by PAUSED 
(Section 8.2) or implicitly determined by previously received PAUSE 
(Section 8.1) or RESUME requests. A randomly chosen PauseID MAY be 
used if it was not possible to retrieve current PauselD information, 
in which case the RESUME will either succeed or the current PauselD 
can be found in a returned REFUSED (Section 8.4). 


If an RTP stream receiver that sent a RESUME with a certain PauselD 
receives a REFUSED with the same PauseID, it is RECOMMENDED that it 
refrains from scheduling further RESUME requests for some appropriate 
time since the REFUSE indicates that it is currently not possible to 
resume the stream. What is an appropriate time can vary from 
application to application and will also depend on the importance of 
resuming the stream, but 1-2 regular RTCP intervals is expected to be 
appropriate. 


RESUME requests MAY be retransmitted, subject to transmission rules 
(Section 8.5), to increase the probability that the message reaches 
the receiver in a timely fashion. The number of repetitions to use 
could be tuned to observed loss rate and desired loss probability, 
for example, based on RTCP reports received from the intended message 
target. Such retransmission SHOULD stop as soon as RTP packets from 
the targeted stream are received or when a REFUSED with the current 
PauselD for the targeted RTP stream is received. 


RESUME has no defined Type Specific parameters. 


When an RTP stream sender in pausing (Section 6.2), paused 

(Section 6.3), or local paused state (Section 6.4) receives a RESUME 
with the current PauseID, and unless local considerations currently 
make it impossible to resume the stream, it SHALL enter playing state 
(Section 6.1) and act accordingly. If the RTP stream sender is 
incapable of honoring a RESUME request with the current PauseID, or 
if it receives a RESUME request with a PauseID that is not the 
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current PauseID while in paused or pausing state, the RTP stream 
sender SHALL schedule a REFUSED message for transmission as specified 
below. 


If an RTP stream sender in playing state receives a RESUME containing 
either the current PauseID or a past PauseID, the received RESUME 
SHALL be ignored. 


8.4. REFUSED 


If an RTP stream sender receives a PAUSE (Section 8.1) or RESUME 
(Section 8.3) request containing the current PauseID, where the 
requested action cannot be fulfilled by the RIP stream sender due to 
some local consideration, it SHALL schedule transmission of a REFUSED 
notification containing the current PauseID from the rejected 
request. 


REFUSED has no defined Type Specific parameters. 


If an RTP stream sender receives a PAUSE or RESUME request with a 
PauseID that is not the current PauseID, it SHALL schedule a REFUSED 
notification containing the current PauseID, except if the RIP stream 
sender is in playing state and receives a RESUME with a past PauselD, 
in which case the RESUME SHALL be ignored. 


If several PAUSE or RESUME requests that would render identical 
REFUSED notifications are received before the scheduled REFUSED is 
sent, duplicate REFUSED notifications MUST NOT be scheduled for 
transmission. This effectively lets a single REFUSED respond to 
several ineffective PAUSE or RESUME requests. 


An RTP stream receiver that sent a PAUSE or RESUME request and 
receives a REFUSED containing the same PauselD as in the request 
SHOULD refrain from sending an identical request for some appropriate 
time to allow the condition that caused REFUSED to clear. For PAUSE, 
an appropriate time is suggested in Section 8.1. For RESUME, an 
appropriate time is suggested in Section 8.3. 


An RTP stream receiver that sent a PAUSE or RESUME request and 
receives a REFUSED containing a PauselD different from the request 
MAY schedule another request using the PauselD from the REFUSED 
notification. 


8.5. Transmission Rules 
The transmission of any RTCP feedback messages defined in this 


specification MUST follow the normal AVPF-defined timing rules and 
depend on the session’s mode of operation. 
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All messages defined in this specification, as well as TMMBR/TMMBN 
used for pause/resume purposes (Section 5.6), can use either Regular, 
Early, or Immediate timings but should make a trade-off between 
timely transmission (Section 4.1) and RTCP bandwidth consumption. 
This can be achieved by taking the following into consideration: 


O It is recommended that PAUSE use Early or Immediate timing, except 
for retransmissions where RTCP bandwidth can motivate the use of 
Regular timing. 


o The first transmission of PAUSED for each (non-wrapped) PauseID is 
recommended to be sent with Immediate or Early timing to stop 
unnecessary repetitions of PAUSE. It is recommended that 
subsequent transmissions of PAUSED for that PauseID use Regular 
timing to avoid excessive PAUSED RTCP bandwidth caused by multiple 
PAUSE requests. 


O It is recommended that unsolicited PAUSED (sent when entering 
local paused state (Section 6.4)) always use Immediate or Early 
timing, until PAUSED for that PauseID is considered delivered at 
least once to all receivers of the paused RIP stream, to avoid RTP 
Stream receivers that take unnecessary corrective action when the 
RTP stream is no longer received, after which it is recommended 
that PAUSE uses Regular timing (as for PAUSED triggered by PAUSE 
above). 


o RESUME is often time critical, and it is recommended that it 
always uses Immediate or Early timing. 


o The first transmission of REFUSED for each (non-wrapped) PauseID 
is recommended to be sent with Immediate or Early timing to stop 
unnecessary repetitions of PAUSE or RESUME. It is recommended 
that subsequent REFUSED notifications for that PauseID use Regular 
timing to avoid excessive REFUSED RTCP bandwidth caused by 
multiple unreasonable requests. 


Signaling 


The capability of handling messages defined in this specification MAY 
be exchanged at a higher layer such as SDP. This document extends 
the "rtcp-fb" attribute defined in Section 4 of AVPF [RFC4585] to 
include the request for pause and resume. This specification follows 
all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an 
"rtcp-fb" attribute relating to the payload type in a session 
description. 
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This specification defines a new parameter "pause" to the "ccm" 
feedback value defined in CCM [RFC5104], representing the capability 
to understand the RICP feedback message and all of the defined FCIs 
of PAUSE, RESUME, PAUSED, and REFUSED. 


Note: When TMMBR 0 / TMMBN 0 are used to implement pause and 
resume functionality (with the restrictions described in this 
Specification), signaling the "rtcp-fb" attribute with the "com" 
and "tmmbr" parameters is sufficient and no further signaling is 
necessary. There is, however, no guarantee that TMMBR/TMMBN 
implementations predating this specification work exactly as 
described here when used with a bitrate value of 0. 


The "pause" parameter has two optional attributes, which are "nowait" 
and "config": 


o "nowait" indicates that the hold-off period defined in Section 6.2 
can be set to 0, reducing the latency before the stream can be 
paused after receiving a PAUSE request. This condition occurs 
when there will only be a single receiver per direction in the RTP 
session, for example, in point-to-point sessions. It is also 
possible to use in scenarios using unidirectional media. The 
conditions that allow "nowait" to be set (Section 6.2) also 
indicate that it would be possible to use CCM TMMBR/TMMBN as 
pause/resume signaling. 


o "config" allows for partial implementation of this specification 
according to the different roles in the use-cases section 
(Section 3) and takes a value that describes what subset is 
implemented: 


1 Full implementation of this specification. This is the default 
configuration. A missing "config" pause attribute MUST be 
treated equivalent to providing a "config" value of 1. 


2 The implementation intends to send PAUSE and RESUME requests 
for received RTP streams and is thus also capable of receiving 
PAUSED and REFUSED. It does not support receiving PAUSE and 
RESUME requests, but it may pause sent RTP streams due to local 
considerations and then intend to send PAUSED for them. 


3 The implementation supports receiving PAUSE and RESUME requests 
targeted for RTP streams it sends. It will send PAUSED and 
REFUSED as needed. The node will not send any PAUSE and RESUME 
requests but supports and desires receiving PAUSED if received 
RTP streams are paused. 
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4 The implementation intends to send PAUSE and RESUME requests 
for received RTP streams and is thus also capable of receiving 
PAUSED and REFUSED. It cannot pause any RTP streams it sends, 
and thus does not support receiving PAUSE and RESUME requests, 
and it also does not support sending PAUSED indications. 


5 The implementation supports receiving PAUSE and RESUME requests 
targeted for RTP streams it sends. It will send PAUSED and 
REFUSED as needed. It does not support sending PAUSE and 

RESUME requests to pause received RTP streams, and it also does 

not support receiving PAUSED indications. 


6 The implementation supports sent and received RTP streams being 
paused due to local considerations and thus supports sending 
and receiving PAUSED indications. 


7 The implementation supports and desires to receive PAUSED 
indications for received RTP streams but does not pause or send 
PAUSED indications for sent RTP streams. It does not support 
any other messages defined in this specification. 


8 The implementation supports pausing sent RTP streams and 
sending PAUSED indications for them but does not support 
receiving PAUSED indications for received RIP streams. It does 
not support any other messages defined in this specification. 


All implementers of this specification are encouraged to include full 
support for all messages ("config=1"), but it is recognized that this 
is sometimes not meaningful for implementations operating in an 
environment where only parts of the functionality provided by this 
specification are needed. The above defined "config" functionality 
subsets provide a trade-off between completeness and the need for 
implementation interoperability, achieving at least a level of 
functionality corresponding to what is desired by the least-capable 
party when used as specified here. Implementing any functionality 
subsets other than those defined above is NOT RECOMMENDED. 


When signaling a "config" value other than 1, an implementation MUST 
ignore non-supported messages on reception and SHOULD omit sending 
messages not supported by the remote peer. One example where it can 
be motivated to send messages that some receivers do not support is 
when there are multiple message receivers with different message 
support (different "config" values). That approach avoids letting 
the least-capable receiver limit the functionality provided to 
others. The below table summarizes per-message send and receive 
support for the different "config" pause attribute values ("X" 
indicating support and "-" indicating non-support): 
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4+---4+----------------------------- 4----------------------------- + 
| # | Send | Receive | 
| | PAUSE RESUME PAUSED REFUSED | PAUSE RESUME PAUSED REFUSED | 
4+---4+----------------------------- 4----------------------------- + 
[aS E < X X X | x X X X | 
2- x X X - | =- - X X | 
3l ES - X X | xX X X - | 
pd X X - - | =- - X X | 
5 - - X X X x - - 

[| 2 = X dq] v x ZI 

[E = - - = oq = - x - | 
Le] - - x zr wh ss - - 2s jj 
4+---4+----------------------------- 4----------------------------- + 


Figure 7: Supported Messages for Different "config" Values 


In the above description of partial implementations, "config" values 
2 and 4 correspond to the RTP Mixer in the 'RTP Mixer to Media 
Sender’ use case (Section 3.2), and "config" values 3 and 5 
correspond to the media sender in that same use case. For that use 
case, it should be clear that an RTP Mixer implementing only "config" 
values 3 or 5 will not provide a working solution. Similarly, for 
that use case, a media sender implementing only "config" values 2 or 
4 will not provide a working solution. Both the RTP Mixer and the 
media sender will of course work when implementing the full set of 
messages, corresponding to "config=1". 


A partial implementation is not suitable for pause/resume support 
between cascaded RTP Mixers, but it would require support 
corresponding to "config=1" between such RTP Mixers. This is because 
an RTP Mixer is then also a media sender towards the other RTP Mixer, 
requiring support for the union of "config" values 2 and 3 or 
"config" values 4 and 5, which effectively becomes "config=1". 


As can be seen from Figure 7 above, "config" values 2 and 3 differ 
from "config" values 4 and 5 only in that in the latter, the PAUSE/ 
RESUME message sender (e.g., the RTP Mixer side) does not support 
local pause (Section 6.4) for any of its own streams and therefore 
also does not support sending PAUSED. 


Partial implementations that only support local pause functionality 
can declare this capability through "config" values 6-8. 


Viable fallback rules between different "config" values are described 
in Section 9.1 and Figure 9. 
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This is the resulting ABNF [RFC5234], extending the existing ABNF in 
Section 7.1 of CCM [RFC5104]: 


rtcp-fb-ccm-param =/ SP "pause" *(SP pause-attr) 
pause-attr pause-config ; partial message support 
"nowait" ; no hold-off period 
byte-string ; for future extensions 
pause-config "config=" pause-config-value 
pause-config-value = 1*2DIGIT 

; byte-string as defined in RFC 4566 


ISS 


Figure 8: ABNF 


An endpoint implementing this specification and using SDP to signal 
capability SHOULD indicate the new "pause" parameter with "ccm" 
signaling but MAY instead use existing "ccm tmmbr" signaling 
[RFC5104] if the limitations in functionality when using TMMBR/TMMBN 
as described in this specification (Section 5.6) are considered 
acceptable. In that case, no partial message support is possible. 
The messages from this specification (Section 8) SHOULD NOT be used 
towards receivers that did not declare capability to receive those 
messages. 


The pause functionality can normally be expected to work 
independently of the payload type. However, there might exist 
Situations where an endpoint needs to restrict or at least configure 
the capabilities differently depending on the payload type carrying 
the media stream. Reasons for this might relate to capabilities to 
correctly handle media boundaries and avoid any pause or resume 
operation to occur where it would leave a receiver or decoder with no 
choice than to attempt to repair or discard the media received just 
prior to or at the point of resuming. 


There MUST NOT be more than one "a-rtcp-fb" line with "pause" 
applicable to a single payload type in the SDP, unless the additional 
line uses "*" as the payload type, in which case "*" SHALL be 
interpreted as applicable to all listed payload types that do not 
have an explicit "pause" specification. The "config" pause attribute 
MUST NOT appear more than once for each "pause" CCM parameter. The 
"nowait" pause attribute MUST NOT appear more than once for each 
"pause" CCM parameter. 


9.1. Offer/Answer Use 
An offerer implementing this specification needs to include the 
"pause" CCM parameter with a suitable configuration attribute 


("config") in the SDP, according to what messages it intends to send 
and desires to receive in the session. 


Burman, et al. Standards Track [Page 37] 


RFC 7728 RTP Stream Pause February 2016 


In SDP offer/answer, the "config" pause attribute and its message 
directions are interpreted based on the agent providing the SDP. The 
offerer is described in an offer, and the answerer is described in an 
answer. 


An answerer receiving an offer with a "pause" CCM line and a "config" 
pause attribute with a certain value, describing a certain capability 
to send and receive messages, MAY change the "config" pause attribute 
value in the answer to another configuration. The permitted answers 

are listed in the below table. 


SDP Offer "config" value Permitted SDP Answer "config" values 


| 
SS ey a ce See ae ee er ee ee qp————————————————————————————————————— 
i les 2295. ag. dr o B ae 8 
2 | 3, 4, 5 6, 7,8 
3 E ENS NS E E 
4 5, 6, 7, 8 
5 | 4, 6 7,8 
6 | 6, 7,8 
7 | 8 
8 Ba: 
Figure 9: "config" Values in Offer/Answer 


An offer or answer omitting the "config" pause attribute MUST be 
interpreted as equivalent to "config=1". Implementations of this 
specification MUST NOT use any "config" values other than those 
defined above in an offer or answer and MUST remove the "pause" CCM 
line in the answer when receiving an offer with a "config" value it 
does not understand. In all cases, the answerer MAY also completely 
remove any "pause" CCM line to indicate that it does not understand 
or desire to use any pause functionality for the affected payload 
types. 


If the offerer believes that itself and the intended answerer are 
likely the only endpoints in the RTP session, it MAY include the 
"nowait" pause attribute on the "pause" line in the offer. If an 
answerer receives the "nowait" pause attribute on the "pause" line in 
the SDP, and if it has information that the offerer and itself are 
not the only endpoints in the RTP session, it MUST NOT include any 
"nowait" pause attribute on its "pause" line in the SDP answer. The 
answerer MUST NOT add "nowait" on the "pause" line in the answer 
unless it is present on the "pause" line in the offer. If both offer 
and answer contain a "nowait" pause attribute, then the hold-off 
period is configured to 0 at both the offerer and answerer. 


Unknown pause attributes MUST be ignored in the offer and MUST then 
be omitted from the answer. 
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If both "pause" and "tmmbr" are present in the offer, both MAY be 
included also in the answer, in which case TMMBR/TMMBN MUST NOT be 
used for pause/resume purposes (with a bitrate value of 0), to avoid 
signaling ambiguity. 


2. Declarative Use 


In declarative use, the SDP is used to configure the node receiving 
the SDP. This has implications on the interpretation of the SDP 
signaling extensions defined in this specification. 


First, the "config" pause attribute and its message directions are 
interpreted based on the node receiving the SDP, and it describes the 
RECOMMENDED level of operation. If the joining client does not 
support the indicated "config" value, some RTP session stream 
optimizations may not be possible in that some RTP streams will not 
be paused by the joining client, and/or the joining client may not be 
able to resume and receive wanted streams because they are paused. 


Second, the "nowait" pause attribute, if included, is followed as 
specified. It is the responsibility of the declarative SDP sender to 
determine if a configured node will participate in a session that 
will be point to point, based on the usage. For example, a 
conference client being configured for an any source multicast 
session using the Session Announcement Protocol (SAP) [RFC2974] will 
not be in a point-to-point session, thus "nowait" cannot be included. 
A Real-Time Streaming Protocol (RTSP) [RFC2326] client receiving a 
declarative SDP may very well be in a point-to-point session, 
although it is highly doubtful that an RTSP client would need to 
support this specification, considering the inherent PAUSE support in 
RTSP. 


Unknown pause attributes MUST be ignored. 

If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST 
NOT be used for pause/resume purposes (with a bitrate value of 0) to 
avoid signaling ambiguity. 


Examples 


The following examples show use of PAUSE and RESUME messages, 
including use of offer/answer: 


1. Offer/Answer 
2. Point-to-Point Session 


3. Point to Multipoint using Mixer 
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4. Point to Multipoint using Relay 
1. Offer/Answer 


The below figures contain an example of how to show support for 
pausing and resuming the streams, as well as indicating whether or 
not the hold-off period can be set to 0. 


v=0 

o=alice 3203093520 3203093520 IN IP4 alice.example.com 
s=Pausing Media 

t=0 0 

c=IN IP4 alice.example.com 

m-audio 49170 RIP/AVPF 98 99 

a-rtpmap:98 G719/48000 

a-rtpmap:99 PCMA/8000 

a-rtcp-fb:* ccm pause nowait 


Figure 10: SDP Offer with Pause and Resume Capability 


The offerer supports all of the messages defined in this 
Specification, leaving out the optional "config" pause attribute. 

The offerer also believes that it will be the sole receiver of the 
answerer's stream as well as that the answerer will be the sole 
receiver of the offerer's stream and thus includes the "nowait" pause 
attribute for the "pause" parameter. 


This is the SDP answer: 


v=0 

o=bob 293847192 293847192 IN IP4 bob.example.com 
s=- 

t=0 0 

c=IN IP4 bob.example.com 

m=audio 49202 RTP/AVPF 98 

a=rtpmap:98 G719/48000 

a=rtcp-fb:98 ccm pause config=2 


Figure 11: SDP Answer with Pause and Resume Capability 


The answerer will not allow its sent streams to be paused or resumed 
and thus restricts the answer to indicate "config=2". It also 
supports pausing its own RTP streams due to local considerations, 
which is why "config=2" is chosen rather than "config=4". The 
answerer somehow knows that it will not be a point-to-point RTP 
session and has therefore removed "nowait" from the "pause" line, 
meaning that the offerer must use a non-zero hold-off period when 
being requested to pause the stream. 
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When using TMMBR 0 / TMMBN 0 to achieve pause and resume 
functionality, there are no differences in SDP compared to CCM 
[RFC5104]; therefore, no such examples are included here. 


10.2. Point-to-Point Session 


This is the most basic scenario, which involves two participants, 
each acting as a sender and/or receiver. Any RTP data receiver sends 
PAUSE or RESUME messages to the sender, which pauses or resumes 
transmission accordingly. The hold-off period before pausing a 
stream is 0. 


4--------------- * 4--------------- * 
| RTP Sender RTP Receiver 
4--------------- * 4--------------- * 

: tl: RTP data 

| ------------------------------- > | 

| t2: PAUSE (3) | 

| <------------------------------- | 

| < RTP data paused > | 

| t3: PAUSED (3) | 

| ------------------------------- > | 

: « Some time passes » : 

| t4: RESUME (3) | 

Ilt | 

| t5: RTP data | 

| ------------------------------- > | 

: « Some time passes » : 

| t6: PAUSE (4) | 

| <------------------==----------- | 

| < RTP data paused > | 

| t7: PAUSED (4) | 

| ------------------------------- > | 


Figure 12: Pause and Resume Operation in Point to Point 


Figure 12 shows the basic pause and resume operation in a 
point-to-point scenario. At time tl, an RTP sender sends data to a 
receiver. At time t2, the RTP receiver requests the sender to pause 
the stream, using PauseID 3 (which it knew since before in this 
example). The sender pauses the data and replies with a PAUSED 
containing the same PauseID. Some time later (at time t4), the 
receiver requests the sender to resume, which resumes its 
transmission. The next PAUSE, sent at time t6, contains an updated 
PauseID (4), with a corresponding PAUSED being sent at time t7. 
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+--------------- + 4+--------------- + 
RTP Sender RTP Receiver 
+--------------- + +--------------- + 
tl: RTP data 
| ----------==------------------- > | 
| t2: TMMBR 0 | 
| <------------------------------- | 
| < RTP data paused > | 
t3: TMMBN 0 
E E E EAE E Ss Se E E > 
: < Some time passes > : 
| t4: TMMBR 150000 | 
| <------------------------------- | 
| t5: RTP data | 
| -----------~------------------- > | 

: < Some time passes > 

| t6: TMMBR 0 | 
| <------------------------------- | 
| < RTP data paused > | 
| t7: TMMBN 0 | 
| comm mmm > | 


Figure 13: TMMBR Pause and Resume in Point to Point 


Figure 13 describes the same point-to-point scenario as above, but 
using TMMBR/TMMBN signaling. 
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+--------------- + 4+---------------- + 
RTP Sender A RTP Receiver B 
+--------------- + 4+---------------- + 
tl: RTP data 
| ------------=------------------ > | 
| < RTP data paused > | 
| t2: TMMBN {A:0} | 
| --------------- Solo > | 

< Some time passes > : 
| t3: TMMER 0 | 
| e EE | 
| t4: TMMBN {A:0,B:0} | 
| --------------- Sto > | 
: < Some time passes > : 
| t5: TMMBN {B:0} | 
| --------------- -------------—-- > | 
: < Some time passes > ; 
| t6: TMMBR 80000 | 
| o o ne mee | 
| t7: RTP data | 
RR > | 


Figure 14: Unsolicited PAUSED Using TMMBN 


Figure 14 describes the case when an RTP stream sender (A) chooses to 
pause an RTP stream due to local considerations. Both A and the RTP 
stream receiver (B) use TMMBR/TMMBN signaling for pause/resume 
purposes. A decides to pause the RIP stream at time t2 and uses 
TMMBN 0 to signal PAUSED, including itself in the TMMBN bounding set. 
At time t3, despite the fact that the RIP stream is still paused, B 
decides that it is no longer interested in receiving the RIP stream 
and signals PAUSE by sending a TMMBR 0. As a result of that, the 
bounding set now contains both A and B, and A sends out a new TMMBN 
reflecting that. After a while, at time t5, the local considerations 
that caused A to pause the RTP stream no longer apply, causing it to 
remove itself from the bounding set and to send a new TMMBN 
indicating this. At time t6, B decides that it is now interested in 
receiving the RTP stream again and signals RESUME by sending a TMMBR 
containing a bitrate value greater than 0, causing A to resume 
sending RTP data. 
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4+--------------- + 4+--------------- + 
RTP Sender RTP Receiver 
4+--------------- + 4+--------------- + 

tl: RTP data 
[e > | 
| t2: PAUSE(7), lost | 
| a E | 
| | 
| t3: RTP data | 
A em ep gn E A AER TS AE tg uy Qus A a quid eg tas E EA > 


| < Time-out, still receiving data > | 
| t4: PAUSE (7) | 
| 
| 


Em +--+ +--+ ++ | 
« RTP data paused » | 
| t5: PAUSED (7) | 
A A E RBRUM PE sl ee Pee e eye a a > 
< Some time passes > : 
| t6: RESUME (7), lost | 
| «---X-------------- | 
| t7: RESUME (7) | 
< SS SS eS Se ee 
| t8: RTP data | 
| --------- 22 2-- nanan nn nnnnn enn > | 
| t9: RESUME (7) | 
e pm ee eee ee | 


Figure 15: Pause and Resume Operation with Messages Lost 


Figure 15 describes what happens if a PAUSE message from an RTP 
stream receiver does not reach the RIP stream sender. After sending 
a PAUSE message, the RTP stream receiver waits for a time-out to 
detect if the RTP stream sender has paused the data transmission or 
has sent a PAUSED indication according to the rules discussed in 
Section 6.3. As the PAUSE message is lost on the way (at time t2), 
RTP data continues to reach to the RTP stream receiver. When the 
timer expires, the RIP stream receiver schedules a retransmission of 
the PAUSE message, which is sent at time t4. If the PAUSE message 
now reaches the RTP stream sender, it pauses the RTP stream and 
replies with PAUSED. 


At time t6, the RTP stream receiver wishes to resume the stream again 
and sends a RESUME, which is lost. This does not cause any severe 
effect, since there is no requirement to wait until further RESUME 
requests are sent, and another RESUME is sent already at time t7, 
which now reaches the RTP stream sender that consequently resumes the 
stream at time t8. The time interval between t6 and t7 can vary but 
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10. 


may, for example, be one RTCP feedback transmission interval as 
determined by the AVPF rules. 


The RTP stream receiver did not realize that the RTP stream was 
resumed in time to stop yet another scheduled RESUME from being sent 
at time t9. This is, however, harmless since RESUME contains a past 
PauseID and will be ignored by the RTP stream sender. It will also 
not cause the RIP stream to be resumed even if the stream was paused 
again based on a PAUSE from some other receiver before receiving the 
RESUME, since the current PauseID was updated compared to the one in 
the stray RESUME, which contains a past PauseID and will be ignored 
by the RTP stream sender. 


4--------------- t 4--------------- t 
RTP Sender | RTP Receiver 
4--------------- t 4--------------- t 
tl: RTP data 
| ~----~------------------------ > | 
| t2: PAUSE (11) | 
E | 
| | 
< Cannot pause RTP data > 

t3: REFUSED (11) 
A REN a 
| t4: RTP data | 
| ------------------------------ > | 


Figure 16: Pause Request is Refused in Point to Point 


In Figure 16, the receiver requests to pause the sender, which 
refuses to pause due to some consideration local to the sender and 
responds with a REFUSED message. 


3. Point to Multipoint Using Mixer 


An RTP Mixer is an intermediate node connecting different transport- 
level clouds. The Mixer receives streams from different RTP sources, 
selects or combines them based on the application's needs, and 
forwards the generated stream(s) to the destination. The Mixer 
typically puts its own SSRC(s) in RTP data packets instead of the 
original source(s). 


The Mixer keeps track of all the streams delivered to the Mixer and 


how they are currently used. In this example, Mixer (M) selects the 
video stream to deliver to the RTP stream receiver (R) based on the 
voice activity of the RTP stream senders (S1 and S2). The video 
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stream will be delivered to R using M’s SSRC and with a CSRC 
indicating the original source. 


Note that PauseID is not of any significance for the example and is 
therefore omitted in the description. 


+----- + 4----- + +----- + 4+----- + 
| Ro | M | | si | | s2 | 
4----- * 4R----- + 4----- * 4----- + 
t1:RTP (S1) : 
| | t2:RTP (M:S1) | <----------------- | | 
| <----------------~ | | | 
| |  t3:RTP (S2) | | 
| lc | 
| | t4: PAUSE(S2) | | 
—À A A et Se ee ee ee ee > 
| | | t5: PAUSED (S2) 
| | <---- nanan a S nnn nnn nanan | 
| | | <S2:No RTP to M> | 
| | t6: RESUME (S2) | | 
| ESE SEDE a >| 
| t7: RTP to M 
< A A A A A A A 
| | t8:RTP (M:S2) | | | 
| | | | 
| | | t9:PAUSE (S1) | | 
| | ----------------- >| | 
t10:PAUSED (S1) 
| qi | 
| | 


| «S1:No RTP to M» | 


Figure 17: Pause and Resume Operation for a Voice-Activated Mixer 


The session starts at tl with S1 being the most active speaker and 
thus being selected as the single video stream to be delivered to R 
(t2) using M's SSRC but with S1 as the CSRC (indicated after the 
colon in the figure). Then S2 joins the session at t3 and starts 
delivering an RTP stream to M. As S2 has less voice activity then 
S1, M decides to pause S2 at t4 by sending S2 a PAUSE request. At 
t5, S2 acknowledges with PAUSED and at the same instant stops 
delivering RTP to M. At t6, the user at S2 starts speaking and 
becomes the most active speaker and M decides to switch the video 
stream to S2 and therefore quickly sends a RESUME request to S2. At 
t7, S2 has received the RESUME request and acts on it by resuming RTP 
stream delivery to M. When the RTP stream from t7 arrives at M, it 
Switches this RTP stream into its SSRC (M) at t8 and changes the CSRC 
to S2. As S1 now becomes unused, M issues a PAUSE request to Sl at 
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t9, which is acknowledged at t10 with PAUSED, and the RTP stream from 
S1 stops being delivered. 


10.4. Point to Multipoint Using Translator 


A transport Relay in an RTP session forwards the message from one 
peer to all the others. Unlike Mixer, the Relay does not mix the 
streams or change the SSRC of the messages or RTP media. These 
examples are to show that the messages defined in this specification 
can be safely used also in a transport Relay case. The parentheses 
in the figures contains (Target SSRC, PauseID) information for the 
messages defined in this specification. 


4------------- * 4------------- * 4------------- * 
| Sender(S) | | Relay | Receiver (R) | 
4------------- * 4------------- * 4------------- * 
tl: RTP (S) 3 

EE S > | | 

| t2: RTP (S) | 

e ue >| 

| 


<Sender waiting for possible RESUME> 
| < RTP data paused > 
| t5: PAUSED (S, 3) | 


| A EE > 

| | > > 

| | t7: RESUME(S,3) | 

| | | 
t8: RESUME (S, 3) | | 

< i a a ee ee 

| t9: RTP (S) | | 

| Raa > | 

| | t10: RTP (S) | 

| | 


Figure 18: Pause and Resume Operation between Two Participants Using 
a Relay 


Figure 18 describes how a Relay can help the receiver (R) in pausing 
and resuming the sender (S). S sends RTP data to R through the 
Relay, which just forwards the data without modifying the SSRCs. R 
sends a PAUSE request to S which, in this example, knows that there 
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may be more receivers of the stream and waits a non-zero hold-off 
period to see if there is any other receiver that wants to receive 


the data, 


pause 
sendi 


and when no disapproving RESUME messages are received, it 


s itself and replies with PAUSED. Similarly R resumes S by 


ng a RESUME request through the Relay. 


Since this describes 


only a single pause and resume operation for a single RIP stream 


sender, all messages use a single PauseID; in this example, it’s 
three. 
+----- + +----- + +----- + +----- + 
| s | | Rel | | RI | | R2 | 
+----- + +----- + +----- + +----- + 
: t1:RTP (S) : : 
|----------------- >| | | 
| | t2:RTP(S) | | 
—-—--------------- »------------------» 
t3:PAUSE(S, 7) | 
| | > | | 
| t4:PAUSE(S,7) | | | 
| > |------------------------------------ >| 
| | | | t5:RESUME(S,7) | 
< See NS ye a a a a A A O A py a a A aS A e A 
| t6:RESUME (S, 7) | | 
| > |----------------- >| | 
| | <RTP stream continues to R1 and R2> | 
| | | t7: PAUSE(S,8) | 
| |<----------------------- == 2-28 === | 
t8:PAUSE(S, 8) 
a ¡AA l | 
| « Pauses RTP stream » | 
| t9:PAUSED (S, 8) | | | 
| >| | | 
t10:PAUSED(S,8) | 
—-—--------------- »------------------» 
| | t11:RESUME (S,8) | | 
| | > | | 
| t12:RESUME(S,8) | | | 
<----------------- | ------------------------------------ > 
t13:RTP (S) | 
| >| | | 
| | t14:RTP (S) | | 
| | -=--------------- >---------------—-- >| 
Figure 19: Pause and Resume Operation between One Sender and Two 
Receivers through Relay 
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Figure 19 explains the pause and resume operations when a transport 
Relay (Rel) is involved between a sender (S) and two receivers (R1 
and R2) in an RTP session. Each message exchange is represented by 
the time it happens. At time t1, S starts sending an RTP stream to 
Rel, which forwards it to R1 and R2. R1 and R2 receives RTP data 
from Rel at t2. At this point, both R1 and R2 will send RTCP 
Receiver Reports to S informing that they received S's stream. 


After some time (at t3), R1 chooses to pause the stream. On 
receiving the PAUSE request from R1 at t4, S knows that there is at 
least one receiver that may still want to receive the data and uses a 
non-zero hold-off period to wait for possible RESUME messages. R2 
did also receive the PAUSE request at time t4 and since it still 
wants to receive the stream, it sends a RESUME for it at time t5, 
which is forwarded to sender S by Rel. S sees the RESUME at time t6 
and continues to send data to Rel, which forwards it to both R1 and 
R2. At t7, R2 chooses to pause the stream by sending a PAUSE request 
with an updated PauseID. S still knows that there is more than one 
receiver (R1 and R2) that may want the stream and again waits a non- 
zero hold-off period, after which, and not having received any 
disapproving RESUME messages, it concludes that the stream must be 
paused. S now stops sending the stream and replies with PAUSED to R1 


and R2. When any of the receivers (R1 or R2) choose to resume the 
Stream from S, in this example R1, it sends a RESUME request to S 
(also seen by R2). S immediately resumes the stream. 


Consider also an RTP session that includes one or more receivers, 
paused sender(s), and a Relay. Further assume that a new participant 
joins the session, which is not aware of the paused sender(s). On 
receiving knowledge about the newly joined participant, e.g., any RTP 
traffic or RTCP report (i.e., either SR or RR) from the newly joined 
participant, the paused sender(s) immediately sends PAUSED 
indications for the paused streams since there is now a receiver in 
the session that did not pause the sender(s) and may want to receive 
the streams. Having this information, the newly joined participant 
has the same possibility as any other participant to resume the 
paused streams. 
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11. 


12: 


IANA Considerations 
Per this specification, IANA has made the following registrations: 


1. A new value for media stream pause/resume has been registered in 
the "FMT Values for RTPFB Payload Types" registry located at the 
time of publication at: «http://www.iana.org/assignments/rtp- 
parameters» 


Value: 9 

Name: | PAUSE-RESUME 

Long Name: Media Pause/Resume 
Reference: RFC 7728 


2. A new value "pause" to be registered with IANA in the "Codec 
Control Messages" registry located at the time of publication at: 
<http://www.iana.org/assignments/sdp-parameters> 


Value Name: pause 
Long Name: Media Pause/Resume 
Usable with: ccm 
Reference: RFC 7728 
Security Considerations 


This document extends CCM [RFC5104] and defines new messages, i.e., 
PAUSE, RESUME, PAUSED, and REFUSED. The exchange of these new 
messages has some security implications, which need to be addressed 
by the user. 


The messages defined in this specification can have a substantial 
impact on the perceived media quality if used in a malicious way. 
First of all, there is the risk for Denial of Service (DoS) on any 
RTP session that uses the PAUSE-RESUME functionality. By injecting 
one or more PAUSE requests into the RTP session, an attacker can 
potentially prevent any media from flowing, especially when the hold- 
off period is zero. The injection of PAUSE messages is quite simple, 
requiring knowledge of the SSRC and the PauseID. This information is 
visible to an on-path attacker unless RTCP messages are encrypted. 
Even off-path attacks are possible as signaling messages often carry 
the SSRC value, while the 16-bit PauseID has to be guessed or tried. 
The way of protecting the RTP session from these injections is to 


Burman, et al. Standards Track [Page 50] 


RFC 7728 RTP Stream Pause February 2016 


perform source authentication combined with message integrity to 
prevent other than intended session participants from sending these 
messages. The security solution should provide replay protection. 
Otherwise, if a session is long lived enough for the PauseID value to 
wrap, an attacker could replay old messages at the appropriate time 
to influence the media sender state. There exist several different 
choices for securing RTP sessions to prevent this type of attack. 

The Secure Real-time Transport Protocol (SRTP) is the most common, 
but also other methods exist as discussed in "Options for Securing 
RTP Sessions" [RFC7201]. 


Most of the methods for securing RTP, however, do not provide source 
authentication of each individual participant in a multiparty use 
case. In case one of the session participants is malicious, it can 
wreck significant havoc within the RTP session and similarly cause a 
DoS on the RTP session from within. That damage can also be 
attempted to be obfuscated by having the attacker impersonate other 
endpoints within the session. These attacks can be mitigated by 
using a solution that provides true source authentication of all 
participants’ RTCP packets. However, that has other implications. 
For multiparty sessions including a middlebox, that middlebox is 
RECOMMENDED to perform checks on all forwarded RTCP packets so that 
each participant only uses its set of SSRCs to prevent the attacker 
from utilizing another participant's SSRCs. An attacker that can 
send a PAUSE request that does not reach any participants other than 
the media sender can cause a stream to be paused without providing 
opportunity for opposition. This is mitigated in multiparty 
topologies that ensure that requests are seen by all or most of the 
RTP session participants, enabling these participants to send a 
RESUME. In topologies with middleboxes that consume and process 
PAUSE requests, the middlebox can also mitigate such behavior as it 
will commonly not generate or forward a PAUSE message if it knows of 
another participant having use for the media stream. 


The above text has been focused on using the PAUSE message as the 
tool for malicious impact on the RTP session. That is because of the 
greater impact from denying users access to RTP media streams. In 
contrast, if an attacker attempts to use RESUME in a malicious 
purpose, it will result in the media streams being delivered. 
However, such an attack basically prevents the use of the pause and 
resume functionality. Thus, it potentially forces a reduction of the 
media quality due to limitation in available resources, like 
bandwidth that must be shared. 


The session establishment signaling is also a potential venue of 
attack, as that can be used to prevent the enabling of pause and 
resume functionality by modifying the signaling messages. The above 
mitigation of attacks based on source authentication also requires 
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the signaling system to securely handle identities and assert that 
only the intended identities are allowed into the RTP session and 
provided with the relevant security contexts. 
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